Various communication devices are available today that are capable of packet-based multimedia communication using IP (Internet Protocol), such as either fixed or mobile computers and telephones. Multimedia services typically entail transmission of encoded data representing media in different formats and combinations. The term “multimedia” will be used in this description to generally represent any choice of media communicated by using the packet based IP (Internet Protocol) transport technology. Multimedia services involves packet-switched communication of data representing different types of media, such as audio, video, images, text, documents, animations, etc.
A network architecture called “IP Multimedia Subsystem” (IMS) has been developed by the 3rd Generation Partnership Project (3GPP) as an open standard for handling multimedia services and sessions in the packet domain. IMS is a platform for enabling services based on IP transport, more or less independent of the access technology used and not restricted to any specific services. Thus, an IMS network controls multimedia sessions but is not used for the actual transfer of payload data which is routed over access networks and any intermediate transport networks including the Internet.
FIG. 1 is an exemplary schematic illustration of a basic network structure for providing multimedia services by means of an IMS service network. A mobile terminal A is connected to a radio access network 100 and communicates with a fixed terminal B connected to another access network 102, in a communication session S involving one or more multimedia services. There may also be an intermediate backbone network as well, not shown, linking the access networks 100 and 102.
An IMS network 104 is connected to the radio access network 100 and handles the session with respect to terminal A, where networks 100, 104 are typically owned by one operator. In this example, a corresponding IMS network 106 handles the session on behalf of terminal B, and the two IMS networks 104 and 106 may be controlled by different operators. Alternatively, two communicating terminals may of course be connected to the same access network and/or may belong to the same IMS network. Terminal A may also communicate with a server instead, e.g. for downloading some media from a content provider. Moreover, if a terminal is roaming in a visited access network, multimedia services are handled by the terminal's “home” IMS network, i.e. where it is registered as a subscriber.
The session S shown in FIG. 1 is managed by specific nodes in each IMS network, here generally referred to as “session managing nodes” 108. These nodes typically include S-CSCF (Serving Call Session Control Function), I-CSCF (Interrogating Call Session Control Function) and P-CSCF (Proxy Call Session Control Function). Each IMS network 104,106 also includes one or more application servers 110 for enabling various multimedia services. Further, a main database element HSS (Home Subscriber Server) 112 stores subscriber and authentication data as well as service information, among other things. IMS network 106 is basically similar to network 104. The various specific functions of the shown network elements 108-112 are generally known in the art, but are not necessary to describe here further to understand the context of the present invention. Of course, the IMS networks 104,106 contain numerous other nodes and functions not shown here for the sake of simplicity.
A specification called “SIP” (Session Initiation Protocol, according to the standard IETF RFC 3261) is used for handling sessions in IMS networks. SIP is an application-layer control protocol for signalling, to create and generally handle sessions over a packet-switched logic. The SIP standard can thus be used by IMS systems and terminals to establish and control IP multimedia communications. SIP itself does not provide multimedia services, but rather makes available a set of primitives that other protocols or applications can use to actually implement such services. For example, a message called “INVITE” is defined in SIP to initiate a session during a set-up procedure, when a certain application has been invoked.
In SIP, an additional protocol is used called “Session Description Protocol SDP”, for describing multimedia sessions by means of an SDP message, which can be embedded as a self-contained body within SIP messages. SDP can thus be used by terminals to provide information regarding their specific capabilities and preferences, in order to negotiate and agree on which session parameters, in particular codecs as well as an IP address and port for media, to use during a forthcoming multimedia session, as is well-known in the art. The above-mentioned SIP INVITE message includes the SDP message with information on one or more required codecs (coders/decoders) and other communication parameters needed for the forthcoming session.
According to 3GPP, it is required that a subscribing communication terminal accessing an IMS network has access to an IMS SIM or “ISIM” (IMS Subscriber Identity Module) application, in order to provide necessary authentication and subscriber data to an operator of the IMS network. Today, only IMS enabled terminals are allowed to access an IMS network.
An ISIM application is typically installed on a Universal Integrated Circuit Card (UICC), analogous to the well-known SIM card for GSM terminals. Terminals equipped with ISIM are referred to as “IMS enabled” terminals. Among other things, an ISIM stores an IMS Private Identity referred to as “IMPI” and at least one IMS Public Identity referred to as “IMPU”, which are both known to the IMS network. IMPI is used for authentication and is not to be disclosed to third parties, whereas IMPU can be used by anyone to identify subscribers and/or their equipment when participating in IMS services, as analogous to an e-mail address or a telephone number. The intention is that each IMPU is associated with an IMS service profile.
While the IMS concept was primarily conceived to enable multimedia services for mobile IP terminals, it can be used regardless of access technology, as mentioned above. In the European Telecommunications Standards Institute (ETSI), a working group called TISPAN (Telecom and Internet Services and Protocols for Advanced Networks) is currently working with the adoption of IMS in fixed networks. It is now also desirable to provide such IMS-based services for a variety of IP terminals connected to a local or private network, particularly a residential or office network environment using, e.g., conventional LAN (Local Area Network) equipment and protocols. The generic term “private network” will be used in the following description to represent any such networks, including LAN, WAN (Wide Area Network) and WLAN (Wireless Local Area Network). Further, the term “device” will be used for any terminal in the private network capable of IP communication.
A private network may include fixed or wireless communication devices that are not IMS enabled, even though they may be “SIP enabled”, while other communication devices in the private network may be neither IMS enabled nor SIP enabled. For example, such plain devices may include fixed and cordless telephones, as well as PC's and so-called STB's (Set Top Boxes) for television sets. The large amount of such existing “home devices” makes it desirable to provide for an inter-working solution between non-IMS devices and the IMS network, to enhance the market for multimedia services.
In order to provide IMS services to non-IMS enabled communication devices, e.g. connected to a private residential or office network, a multimedia gateway referred to as a “Home IMS Gateway HIG”, has been defined that can act as an IMS enabled terminal on behalf of any communication device connected thereto. This type of Home IMS Gateway is described in applicant's earlier patent application PCT/EP2005/055248. Among other things, the HIG includes a SIP “Back-to-Back User Agent” (B2BUA) for interworking between SIP enabled but non-IMS enabled devices and the IMS network. The B2BUA is equipped with an ISIM application and handles IMS signalling on behalf of SIP devices, such that all signalling concerning an SIP device is associated with the corresponding IMPI on the ISIM application. For example, an SIP enabled device may send an SIP REGISTER message to the HIG, containing only an SIP identity. The HIG will then translate the message into an IMS REGISTER message that contains both an IMPI and an IMPU, according to regular IMS procedures.
A typical scenario for using a HIG is generally outlined in FIG. 2, illustrating a private or “home” environment 200, such as a family residence or an office, that contains a plurality of different IP communication devices linked together in a private network 202. As illustrated here, these devices may include a wireline telephone, a cordless telephone, a TV set, a server and a PC, and these will be simply referred to as “devices” hereafter.
The private network 202 includes a conventional residential gateway RGW 204 which is connected to an external access network 206, providing a communication link for media M to and from the devices in network 202. Although not specifically illustrated here, the RGW 204 typically includes NAT (Network Address Translation) and firewall functions, and also a local DHCP (Dynamic Host Configuration Protocol) server providing private IP addresses to the devices, as is well-known in the art.
The private network 202 further includes a HIG 208 providing a connection to an IMS network, here illustrated as an IMS core 210 containing an HSS 212, among other things. The HIG 208 is equipped with interfaces towards the different types of devices for signalling, using device-specific protocols. In the patent application PCT/EP2005/055248, the basic functional architecture of HIG, including various interfaces, protocol translation and gateway functions, is described in detail. However, these configuration specifics are not necessary to describe here further in order to understand the present invention. In practice, the described HIG functionality may be implemented as a separate node, or in an RGW, or even in an IMS enabled terminal. However, it is considered as a separate functional unit in this description regardless of implementation.
In the HIG 208, identity information 214 is stored for each of the devices in the network 202, typically including the above-mentioned IMPU, which is valid for accessing the IMS core 210 where the same identity information is also stored as subscriber information 216 in the HSS 212, as indicated in the figure. The patent application PCT/EP2005/055248 outlines how different combinations of IMPI and IMPU can be used in this context. Thus, each device in network 202 has been assigned a valid IMS identity, e.g. including an IMPU, which is associated with its local IP address. The identity information 214 is typically stored in an ISIM application implemented in the HIG 208.
Thus, when a device in network 202 sends a request for an IMS service, using a protocol within its capability, the HIG 208 identifies the device by means of its local IP address, and retrieves the IMS identity 214 associated with that device. Then, the HIG can translate the received service request and create a valid SIP-based IMS request (e.g. SIP INVITE) on behalf of the device, using the retrieved IMS identity 214. HIG 208 will then set up a session for the device by communicating suitable SIP messages with the IMS core 210, accordingly.
In a similar manner, an incoming call involving an IMS service, that may be addressed to one of the devices or generally to the private home or office, can be set up by the HIG on behalf of a device using an IMS identity 214 associated with the device. The call can then be routed to the called device over the RGW 204 to communicate media M. In this way, the IMS core will perceive the device 202 as an IMS enabled device, and the device will use the HIG 208 as a proxy for accessing services offered by means of the IMS network.
However, this procedure requires that a valid IMS identity must be assigned for each device in the private network 202, including necessary authentication data, in the HIG. The IMS network operator typically hands out IMS identities which also must be registered in the IMS network as subscriber information stored in the HSS 212. Each time a device is added to the network, a new IMS identity must be assigned thereto. Consequently, the IMS identity setup at both locations 208, 212 must be modified each time a device is added or removed from the local environment, i.e. the private network 202.
This somewhat inflexible solution places an unwanted administration burden on the user and the IMS operator, and it is not evident how a user should handle the IMS identities, e.g. IMPU's. Moreover, the IMS network may become loaded with numerous IMS identities and subscriptions that must be managed. A more flexible and convenient solution is thus desirable for providing access to IMS services for non-IMS enabled devices.